The present invention relates to the field of data processing and in particular to dynamically modifying the allocation of program libraries available to an application server.
An application server is a software engine that delivers applications to client applications. Defining the executable application resources available to an application server is a basic capability. How a server manages changes to the executable resources available to it can be a significant distinguishing feature. Typically, the executable resources exist in a file system made available to the server by the hosting operating system, and some mechanism is used to identify a subset of the file system where the server can find the resources it can load and execute. Such executable resources may include programs, functions, mapsets, partitionsets, subroutines, methods, procedures, modules or subprograms, and are hereinafter referred to collectively as ‘programs’.
Many application servers statically define the set of locations within a file system in which programs can be found (in order to be loaded and executed as part of an application). Usually a program loader is provided with a specification of the location of directories containing such programs, rather than with the location of the individual programs themselves. This means that once such a specification is active it is possible to add or remove programs to those directories. The specification comprises an ordered list of locations, and when a program is to be found and loaded, the server runtime (program loader) will systematically search through the listed locations until the first instance of the requested program is found.
In some systems the ordered list of locations is defined as a search path which specifies an ordered list of file system directories in which to look for programs. In a JVM (Java® Virtual Machine) or a Java-based server, such as IBM®'s WebSphere® Application Server, the search order is defined by the classpath. In other systems, such as IBM's CICS® Transaction Server, the ordered list of locations is a list of file (dataset) names, which in CICS Transaction Server is called the DFHRPL DD (Data Definition) concatenation.
In each of these cases, the set of locations is predefined. They must exist when the server starts, and standard operating system mechanisms are used to specify them to the server at startup. Examples of such standard operating system mechanisms include JCL (Job Control Language) for IBM's z/OS® operating system or the classpath environment variable for Java-based servers.
Currently, there is no way for an administrator of such a server to change the set of locations that the server is to use, other than by modifying the pre-defined specification and restarting the server. Where 24×7 (continuous) operation is a high priority, this leads to a tension between a natural structure of program libraries that reflects the structure of the applications hosted in the servers, and a structure that supports the day-to-day operational needs of system programmers running the servers. For example, to accommodate fixes to the applications it is common to use a ‘fixes’ library at the head of the search order into which fixed programs can be added. Also, due to the static nature of the set of locations, it is easier and less disruptive to have a few directories and force all the applications into them than to have an extensive list of application-specific directories.